MVVMとBindingとWPFとWindows Phone

「MVVMは何となく避けて通っていた」

「なぜ」

「昔、MVCってのがあったんだよ」

「今でもあるよ」

「そこは突っ込むな。ともかくMVCは上手く機能しなかった」

「だから、名前が似ているMVVMを避けて通ったわけだね」

「まあ、そうだな」

「でも、違ったの?」

「そうだ。違った、Windows Phoneのコードを書いていて、ふと書いてきたソースを振り返った瞬間に驚いた」

「なぜ?」

「しっかりMVVMになっていたからだ」

「じゃあ、君がこうなるべきだと思って勝手に書いたコードがMVVMだったということ?」

「この場合はそういうことになる」

「それはなぜ?」

「WPFというか、Windows Phoneのアーキテクチャがそれを求めているので必然的にそうなった、という解釈もできるが、どうもそうでもない感じだ」

「というと?」

「昔々、MFCにはModelとViewがあったけどさ。基本的にViewはModelを知ってるけど、ModelはViewを知らない構造なんだ」

「そうか」

「でもさ。実際は両者が協調して動作しないととても性能が出せない」

「PCの性能が足りないってことだね」

「そうじゃない。PCの性能が上がっても焼け石に水だ」

「じゃあ、何?」

「MVVMのVとVMは双方向でインタラクトできるんだ」

「えっ?」

「WPFのバインディングで双方向のインタラクトが指定できるから、VM上でのデータ変更をVに反映することも、Vのレイヤーで起きたユーザー入力を自動的にVM上のデータに反映させることもできる」

「でもさ。2つを分けないで1つで書けばいいじゃん。面倒な連動なんて考えないでさ」

「そうじゃない。分けるメリットがあるんだ」

「えっ?」

「だからさ。VMレベルは抽象的な情報を提供するだけだが、Vレベルでは見せる実態を決める。だから、見かけをいじる場合は多くの場合Vだけでいい。必要な情報が提供されていない場合はVMもいじる必要があるけどね」

「それはいいことなの?」

「そうだ。外見の調整はよくある要求だが、それによって重要なロジックを壊してしまう可能性を減らせる」

「そうか」

「まあ、他にもいろいろあるけどな。まあ、自分のやっていたことが結果としてMVVMだと気づいた以上、これからはもっと意識的にMVVMしていくか」

「つまり、上から読んでもMVVM、下から読んでもMVVMってことだね」